Description

This PoC PR introduces a possible design of a governance framework to address #12 for the solidity-ibc-eureka contracts using a multisig approach based on Safe. The key features implemented include:

1. Multisig (Safe): Critical administrative actions (e.g., upgrades, ownership transfers, pause) require approval from a quorum of pre-defined signers.

2. Upgradeable: The contracts use OpenZeppelin's Transparent Proxy for upgradeability, enabling secure and controlled updates to the system's logic without disrupting its state.

3. Pausable: Leveraging OpenZeppelin's Pausable module, this feature allows authorized actors to temporarily halt IBC operations during emergencies for quick mitigation of potential exploits or failures.

These components together enhance the security, flexibility, and decentralization of the IBC Solidity contracts, laying the groundwork for a robust governance model.

PoC Architecture:

Notes

• the core of the PoC is the MultisigIBCUpgradeTest.t.sol. This test files shows how to wire all the new additions during deployment.
• original safe contracts have been modified to be compiled at the current repo version 0.8.28 by introducing the clause assembly ("memory-safe") before assembly code.
• IBC contracts changes:

1. add Openzeppelin Pausable contract and whenNotPaused modifier for external functions.
2. change the constructor and define an initialization functions for proxy functionalities.

TimeLock

The Timelock mechanism is not currently implemented in this PoC but could be introduced in the future to enhance transparency specifically for upgrades. By delaying the execution of administrative actions, it would allow stakeholders to review proposed changes and raise objections if necessary. This would work well for upgrades but should not be applied to emergency operations, such as pausing, to avoid delays in critical scenarios. Balancing the delay duration would be key to maintaining flexibility while ensuring community trust

Security Consideration

Using proxy contracts requires careful security consideration. The aspect to be considered includes but are not limited to:

• Access Control
• Storage Collision among proxy and implementatinos
• Initialization (possible frontrunning and manipulation)

For an initial review of potential security concern we refer to 1,2,3,4.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
• Wrote unit and integration tests.
• Added relevant natspec and godoc comments.
• Provide a conventional commit message to follow the repository standards.
• Re-reviewed Files changed in the GitHub PR explorer.
• Review SonarCloud Report in the comment section below once CI passes.